 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| AN1796/1103 1/17 rev. 1.0 AN1796 application note field updates for flash based st7 applications using a pc comm port by dennis nolan introduction having the capability to update software in a microprocessor while the part remains in-circuit has proven to be a very valuable feature of the new flash based micro controllers. generally, this has been accomplished via a special dedicated connector (something like a 10 pin header) on the board which talks to a specialized programmer which, in turn, is controlled by a pc. while the cost of these programmers has come down steadily, mostly due to increased capabilities of the mcus to virtually program themselves, they are still not very available to the end user. the purpose of this note is to present practical software techniques which can be built into virtually any application which includes an rs232 serial port to allow the flash based st7 mcu to be updated by any end user in the field. the software presented here is a small (less than 500 bytes) boot loader which will allow for the operating software in the st7 to be replaced safely and reliable by use of a standard s- records format file which can either be emailed to an end user or made available for download on a web site. the pc side of the software update operation can easily be accomplished using any of a number of terminal emulation programs. in this note the operation will be de- scribed using the hyperterminal program which is available to all windows based pc users since it comes bundled with the operating system. 1
2/17 field updates for flash based st7 applications using a pc comm port 1 flash memory sectors we will divide flash memory within the st7 into two sectors by selection within the option byte when the chip is programmed using a standard programmer. these sectors are referred to as sector0 and sector1. the selection at program time is to decide what will be the size of sector0, with the balance of the available memory going to sector1. the boot loader program is less than 500 bytes in size so when programming the part select the smallest size for sector0, which is 0.5k or 512 bytes. the only real distinction between sector0 and sector1 is that sector0 is always write protected as it pertains to in application programming (under direct st7 program control). sector0 can always be programmed by a dedicated programmer but it cannot be written to by the mcu itself. sector1 can be programmed either by a dedicated pro- grammer or by software executing on the mcu itself. sector0 is always the uppermost part of memory so that it includes the reset and interrupt vectors (data that one always wants to be write protected in order to make a self updateable system bulletproof in the face of catastro- phes such as power failures in the middle of an update). since the entire boot loader code and the vectors reside in the write protected sector0 it is always possible to recover from a problem during an update transfer by simply resetting the st7, which will get us back to the boot loader. the example program was written for the st72264 which has 8k of flash so sector1 occupies from $e000 to $fdff and sector0 from $fe00 to $ffff. 2 3/17 field updates for flash based st7 applications using a pc comm port 2 absolute adresses and vectors the example program was written for the st72264 but, so long as the reset and interrupt vector locations are the same, it can be executed without change on any st7 regardless of the size of its flash memory. this is because whatever the size of the flash, it will occupy the top of the 0000 to $ffff 64k possible addressing space of an st7. we would thus always want sector0 to occupy the top 0.5k, the space from $fe00 to $ffff. we would also want the skip- jump table (which is technically part of sector1) to always be located in the area just below sector0 (also the top of sector1). in the example program this table occupies from $fdd0 to $fdff. looking at the vector section at the end the program, the segment directive is used to place the program pointer at each of the absolute memory locations for the various interrupt vectors (and the reset vector) as described in the data sheet for the mcu. at each of these lo- cations, a dc.w directive is used to place a 16 bit absolute address vector. in most micro con- troller software we would be more accustomed to seeing a symbolic (and relocatable) address reference used here and this points out an important concept that must be understood. after we make our first version of the software application and send it out into the world by pro- gramming it into the mcu with a standard programmer (sector0 and sector1), sector0 will probably (if all goes according to plan) never be changed again, although sector1 can have many revisions. when sector1 code is revised, the addresses of any or all of the interrupt service routines associated with the interrupt vectors will move. since sector0 and the vector table will not change we need the address references in the vector table to be fixed. this lim- itation would cause a severe loss of flexibility in the program if it were not for the use of the skip-jump table located at $fdd0. this table has one entry for each interrupt vector. the table consists of long jump (to cover the entire 64k space) instructions spaced every four bytes. ac- tually a long jump only takes up three bytes (one for the jp op code and two for the address) but its easier to count by four. please note that, in the example program, all of the jumps are to the symbolic (and re-locat- able) address dummyisr except for the one associated with the reset vector, which jumps to start. this is because the example program does not make use of any interrupts. the pro- gram must provide a mechanism to use any of the interrupts since we cannot get at the vector table once we send our program out into the world. if we send out a version 1.0 of our application which perhaps uses only the sci interrupt and later decide to revise the program and make use of the timera interrupt we can do that by simply replacing the appropriate jp dummyisr instruction in the skip-jump table with a jump to our timera interrupt service rou- tine. since the skip-jump table resides in sector1 we are free to change the destination of the jumps whenever we please although the absolute location of the jump instruction itself is fixed so that it always agrees with sector0. a careful examination of the reset vector reveals that it is treated specially. this vector does use a symbolic (and re-locatable) address reference, bank0. this is permissible because 4/17 field updates for flash based st7 applications using a pc comm port the destination is within sector0 and so the two will always stay in sync. at power-up reset we always want to execute code in sector0 which is write protected and gives the decision point to either read in an s-records file to update sector1 or exit to execute normal code in sector1. the exit to sector1 is done via a jump to absolute address $fdfc which is an entry in the skip- jump table containing a re-directing jump to start. note : time delays within this program are implemented as simple countings loops. if the main crystal clock is other than 8 mhz then times will change accordingly. 5/17 field updates for flash based st7 applications using a pc comm port 3 using the program with hyperterminal configure hyperterminal as follows: 1. select files->properties 2. click the connect to tab 3. at connect using select direct to com1, 2,3, or 4 as appropriate. 4. click configure and select bits per second: 9600 data bits: 8 parity: none stop bits: 1 flow control: none 5. click the settings tab 6. select emulation: ansi 7. click ascii setup and C uncheck all boxes except append line feeds to incoming line ends C set character delay to 0 milliseconds C set line delay to 20 milliseconds note: a proper line delay setting is crucial to proper operation of the system. the st7 needs this time to store the data in an s-records line before it is ready to receive the data from the next line. after hyperterminal has been configured select file-> save as to save the program con- figuration as a .ht file. afterwards, just clicking the .ht file will open hyperterminal with the required settings. load the example program into the mcu, connect the target to the pc via rs232, and start up hyperterminal. after hyperterminal has started, reset the mcu. after approximately five sec- onds the mcu will transmit a single dollar sign ($) character which will appear on the pc mon- itor. be sure not to press any keys on the keyboard during the five second interval. if the $ is not observed, double check the program configuration and the comm port selection. once the $ character has been observed, reset the mcu and, within five seconds, press any printable key on the keyboard. this key will be echoed back to the monitor and will indicate that the st7 is now in a mode where it will wait indefinitely to receive an s-records file update for sector1. at this point, do the following with hyperterminal: 1. select transfer->send text file 2. select files of type: all files (*.*) 6/17 field updates for flash based st7 applications using a pc comm port 3. navigate to the location of your .s19 s-records file and double click it. at this point you should see the s-records data scroll past on the screen since the st7 echoes the data back to the terminal as it is received and stored. once the entire file has been received the boot loader will force a cold reset on the processor in order to safely lock-up the flash against any further writes. after the five second wait interval another $ character will be transmitted. the program section which transmits the $ is at the label start and is actually the entire sector1 program in this example. after sending the $, execution falls into an endless loop at label loop1. as a suggested exercise, go to the example program source file and change the character that is transmitted from $ to some other printable character and then re- build the application. now start up hyperterminal and reset the st7. after five seconds the $ character will appear (remember, we havent transmitted the new file yet). now reset the mcu and, within five seconds, press any printable character on the keyboard. the character will be echoed back to the screen indicating that the st7 is waiting for a file. do the transfer- >send text file procedure and send the .s19 file for the example (now slightly modified). the file will scroll by on the screen and, after five seconds, whatever character you have re- placed the $ with will appear on the screen. congradulations: youve used hyperter- minal to do a field update of your application program via rs232. 7/17 field updates for flash based st7 applications using a pc comm port 4 decision point at the label bootupwait the program enters a five second loop where it continually polls to see if a uart character has been received. if a character is detected then execution jumps to the label doupdate where the flash memory is unlocked and the program waits patiently to receive the s-records update file. if the five second period expires without detection of a uart character then execution escapes to the entry point for sector1 code (the jp $fdfc in- struction). while this is a good method to use for an example program because it will run prop- erly out of the box on any st7 based system that has a rs232 port it may not be the best choice in all situations. it may be undesirable, for example, that the system will always delay for five seconds after power up before starting to execute the normal program or it may be dif- ficult to arrange for the triggering character to be send to the board within five seconds after power up reset. one alternative method would be to dedicate a general purpose port pin to control the func- tion. in the hardware, we could include a pull-up resistor to vcc at the pin and provide a jumper that would ground the pin if installed. the jumper would normally be installed and we would only remove it if an update was desired. the code at bootupwait can be changed so that the port pin is examined. if the input is logic low, execute the jump to $fdfc without delay to start normal operation. if the pin is high then the program can wait until the jumper is re-installed and then jump to doupdate to receive a new program. normally, the jumper would always be installed. to do an update we would remove the jumper, power up (reset) the st7, replace the jumper and then transmit the file. after the file has been received a cold reset will follow and, because the jumper is installed, normal execution will commence. if an application is tight on i/o and cannot afford to dedicate a pin to this function another ap- proach is to insert a jumper between the output of the rs232 line receiver and the rx input of the st7 and then provide a 10k pull down resistor to ground at the pin of the st7. normally, the jumper would be installed. since the normal marking state of the rx signal is logic high, the code at the decision point can examine the pin (as just a general i/o pin) and, if it is high, exit normally to sector1. if the pin is low (jumper has been removed) then the program would wait until the pin goes high, then jump to doupdate and wait to receive a new file. to perform an up- date one would then remove the jumper and power up (reset) the st7, install the jumper, and then transmit the file. after the file has been received a cold reset will follow and, because the jumper is installed, normal execution will commence. 8/17 field updates for flash based st7 applications using a pc comm port 5 appendex1: software source st7/ #include "264regs.inc" segment byte at: e000 'program' ;******** entry point for sector1 code ********** start: ld a,#'$' ld scidr,a ; transmit character loop1: jrt loop1 ;**** default interrupt service routine **** dummyisr: iret ;**************** skip-jump table ****************** segment byte at: fdd0 'program' ; i^2c jp dummyisr segment byte at: fdd4 'program' ; sci jp dummyisr segment byte at: fdd8 'program' ; avd jp dummyisr segment byte at: fddc 'program' ; timer b jp dummyisr segment byte at: fde0 'program' ; mcc jp dummyisr segment byte at: fde4 'program' ; timer a jp dummyisr segment byte at: fde8 'program' ; spi jp dummyisr segment byte at: fdec 'program' ; css jp dummyisr segment byte at: fdf0 'program' ; ei1 jp dummyisr segment byte at: fdf4 'program' ; ei0 jp dummyisr segment byte at: fdf8 'program' ; trap jp dummyisr 9/17 field updates for flash based st7 applications using a pc comm port segment byte at: fdfc 'program' ; skip jump from bank0 jp start ;*************** sector0 code *********************************** segment byte at: 80-ff 'bank0ram0' b0byte0: ds.b 1 bytecount: ds.b 1 loadaddress: ds.w 1 checksum: ds.b 1 flashbuffer: ds.b 32 ramcode: ds.b 40 segment byte at: fe00 'program' bank0: nop nop sim ; globally disable interrupts ld a,#%11010010 ; set baud rate to 9600 ld scibrr,a ld a,#%00001100 ; enable sci transmitter and receiver ld scicr2,a ; copy the loader routine from rom to ram clr x ramtransfer: ld a,(flashprogrammer,x) ld (ramcode,x),a inc x cp x,#40 jrne ramtransfer bootupwait: ld x,#55 ; 5 seconds clr y clr a 10/17 field updates for flash based st7 applications using a pc comm port charcheck: btjt scisr,#5,doupdate ; jump out and do update if character re- ceived dec a jrne charcheck dec y jrne charcheck dec x jrne charcheck jp $fdfc ; timed out, escape to bank1 doupdate: ; unlock flash control register ld a,#$56 ld fcsr,a ld a,#$ae ld fcsr,a ld a,scidr ld scidr,a ; echo character jrt checkfors b001: call waitforchar checkfors: cp a,#'s' jrne b001 ; loop back until s is received call waitforchar cp a,#'1' jreq gots1 ; jump if this is a s1 record cp a,#'9' jreq gots9 ; jump if this is a s9 record jrt b001 ; otherwise, loop back gots1: call getbinary sub a,#3 ; account for address and checksum bytes ld bytecount,a ;byte count saved call getbinary ld loadaddress,a ;high byte of load address saved call getbinary 11/17 field updates for flash based st7 applications using a pc comm port ld {loadaddress+1},a ; low byte of load address saved clr x b002: cp x,bytecount jreq b003 call getbinary ld (flashbuffer,x),a inc x jrt b002 b003: call getbinary ld checksum,a ; checksum for line saved call ramcode waitforcr: call waitforchar cp a,#13 jrne waitforcr jrt b001 gots9: call waitforchar cp a,#13 jrne gots9 bset wdgcr,#7 ; force a cold reset by starting watchdog bres wdgcr,#6 ; and then sitting in an endless loop gots9a: jrt gots9a; endless loop waiting for watchdog to ; force a reset ;****************** bank zero subroutines ************************* waitforchar: btjf scisr,#5,waitforchar ld a,scidr ld scidr,a ; echo character ret 12/17 field updates for flash based st7 applications using a pc comm port ; reads two successive characters from the character stream (hex-ascii) ; and returns them in a as a byte getbinary: call getdigit swap a ld b0byte0,a call getdigit add a,b0byte0 ret ; this subroutine gets copied to and is executed out of ram flashprogrammer: clr x latchenable: bset fcsr,#1 ; enable xflash latches fp004: cp x,bytecount jreq fp005 ld a,(flashbuffer,x) ld ([loadaddress.w],x),a inc x ld a,x add a,{loadaddress+1} and a,#$1f jrne fp004 ; apply programming pulse bset fcsr,#0 ; set pgm fp006: btjt fcsr,#0,fp006 jrt latchenable fp005: ; apply programming pulse bset fcsr,#0 ; set pgm fp007: btjt fcsr,#0,fp007 nop nop ret ; receives a hex-ascii character and converts to binary getdigit: call waitforchar sub a,#48 cp a,#9 jrule getdigita 13/17 field updates for flash based st7 applications using a pc comm port sub a,#7 getdigita: ret ;**************** interrupt vectors ******************* segment byte at: ffe4 'vector' ; i^2c dc.w $fdd0 segment byte at: ffe6 'vector' ; sci dc.w $fdd4 segment byte at: ffec 'vector' ; avd dc.w $fdd8 segment byte at: ffee 'vector' ; timer b dc.w $fddc segment byte at: fff0 'vector' ; mcc dc.w $fde0 segment byte at: fff2 'vector' ; timer a dc.w $fde4 segment byte at: fff4 'vector' ; spi dc.w $fde8 segment byte at: fff6 'vector' ; css dc.w $fdec segment byte at: fff8 'vector' ; ei1 dc.w $fdf0 segment byte at: fffa 'vector' ; ei0 dc.w $fdf4 segment byte at: fffc 'vector' ; trap dc.w $fdf8 segment byte at: fffe 'vector' ; reset dc.w bank0 end 14/17 field updates for flash based st7 applications using a pc comm port 6 appendex2: blow by blow software description 6.1 power-up initialization at power up reset the vector at $fffe is fetched, which branches execution to the code label bank0. at bank0 interrupts are disabled, the uart baud rate is set to 9600 and the uart transmitter and receiver are enabled. next the 40 byte routine at label flashprogrammer is copied from its location in flash to a block in ram. this is the code which actually writes to the flash and it is necessary that this code be executed out of ram since, once the write se- quence to flash is started, data cannot be read out of flash until the write is completed. 6.2 to update or not to update at label bootupwait a 24 bit counter made up of concatenated registers x:y:a is load with $550000 and then the polling loop starting at label charcheck is cycled through a total of 5,570,560 times, each time checking to see if a uart character has been received. with an 8 mhz effective clock, this polling will take about five seconds. if no character is detected then the jp $fdfc instruction branches execution to the normal sector1 program via the skip- jump table. at label charcheck, if a character is detected then execution branches to label doupdate. 6.3 update to begin the flash update process a sequence of two unique keys are written to control reg- ister fcsr. this exact data in this exact sequence must be written to this register in order to remove write protection from the flash. if any other data is written, the protection will lock up until the next reset of the mcu. next, whatever character had been received in order to acti- vate the update sequence is echoed back to the operator terminal as a confirmation. 6.4 interpreting the s-records file at label b001 the subroutine waitforchar is called. this routine will poll indefinitely waiting for a character to be received by the uart and then echo back the character to the terminal and return it in the a register. since an s-records line must start with an upper case s, the program will loop back through label b001 until an s is seen. next the program looks for either a 1 or a 9 to indicate an s1 or s9 record. anything else is discarded as an error and ex- ecution goes back to label b001 to look for an s again. at label gots1 subroutine getbi- nary is called. this routine will read two characters from the character stream, convert them from hex/ascii to binary format, and return the number in register a. this number is the nn record (see appendix 3) which is the total number of bytes in the record. to get the number of actual data bytes in the record, 3 is subtracted from the value to account for the two address and one checksum byte that are included in the total count. this is saved in the variable 15/17 field updates for flash based st7 applications using a pc comm port bytecount. getbinary is called twice more to retrieve the high and low bytes of the 16 bit load address, which is stored in variable loadaddress. at label b002 a code loop is formed that will read all of the data bytes from the character stream and store them in the linear buffer flashbuffer. at label b003 the checksum is read form the character stream and stored as variable checksum. this program does not make use of the checksum but it is made available here for any future enhancements. now the subroutine ramcode is called. the label ramcode is actually the 40 byte block of ram where the flash writing routine was copied from flash at power-up initialization. we will now examine the code at label flashprogrammer. first, the x pointer is cleared and the flash programming latches are enabled. label fp004 is the top of the program loop. the test for the normal exit condition from the loop is at the top of the loop. when the pointer is equal to the byte count then execution transfers to label fp005. be- fore the loop is exited, each byte in the linear flashbuffer is written to its proper load ad- dress. the low byte of the destination address is also checked to see if it has crossed any 32 byte sector boundary (any change in the upper 11 address bits). this check is necessary be- cause of the hardware of the flash programming latch. the latch only has five address lines and thus the upper 11 address lines must not change during a single write sequence or writing will wrap around and start overwriting earlier data. if the load address is about to cross a 32 byte sector line then the program must fall out of the loop and activate the flash programming sequence with the bytes it has transferred so far. at label fp006 the program waits until the hardware programming of the flash is complete and then transfers back to label latchen- able where transfer continues until the pointer is equal to the bytecount, at which point a programming pulse is applied to complete the programming of the last of the bytes from the s- records line. the subroutine will then return back to the main program at label waitforcr where the program will wait to receive the carriage return which terminates the s-records line and then jump back to label b001. back at b001 we are ready to receive and handle any additional s1 records until, eventually, an s9 record is received. this will cause execution to transfer to label gots9 where the pro- gram will read and discard characters until the carriage return that terminates the s9 record is recognized. at that point the program forces a cold reset to occur by starting the watchdog timer and then falling into an endless loop at label gots9a until the watchdog times out and forces a hardware reset. the cold reset is needed to lock up the flash memory array against any further writes. the st7 does not include a reset instruction so the watchdog was used to force the situation. 16/17 field updates for flash based st7 applications using a pc comm port 7 appendex3: s-records format description data record: 'stnnaaaadddddddddddddddddddddddddddddddd...cc 17/17 field updates for flash based st7 applications using a pc comm port the present note which is for guidance only aims at providing customers with information regarding their products in order for them to save time. as a result, stmicroelectronics shall not be held liable for any direct, indirect or consequential damages with respect to any claims arising from the content of such a note and/or the use made by customers of the information contained herein in connection with their products. information furnished is believed to be accurate and reliable. however, stmicroelectronics assumes no responsibility for the co nsequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. no license is granted by implication or otherwise under any patent or patent rights of stmicroelectronics. specifications mentioned in this publicati on are subject to change without notice. this publication supersedes and replaces all information previously supplied. stmicroelectronics prod ucts are not authorized for use as critical components in life support devices or systems without express written approval of stmicroelectro nics. the st logo is a registered trademark of stmicroelectronics. all other names are the property of their respective owners ? 2003 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia C belgium - brazil - canada - china C czech republic - finland - france - germany - hong kong - india - israel - ital y - japan - malaysia - malta - morocco - singapore - spain - sweden - switzerland - united kingdom - united states www.st.com |
Price & Availability of AN1796
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |